\chapter {Conclusioni}
\label {conclusioni}
Nella realizzazione del prototipo si \`e partiti da una prima fase di analisi del problema in cui l'obiettivo era l'individuazione di un metodo per la misura della similarit\`a tra programmi funzionali. A seguito delle sperimentazioni effettuate possiamo concludere che la teoria degli isomorfismi di tipo \`e risultata essere adatta a questo scopo. Questa teoria, la quale viene attualmente utilizzata prevalentemente nei sistemi di ricerca di funzioni all'interno di database, \`e stata analizzata per verificarne l'applicabilit\`a nel nostro contesto. Da un esame della struttura dei programmi che avevamo a disposizione \`e risultato che quelli appartenenti alla stessa specifica avevano una struttura dei tipi tale per cui solo i progetti realmente plagiati presentavano caratteristiche di isomorfismo. 


Una volta stabilito che questa teoria potesse fare al caso nostro si \`e passati al design dell'applicazione vera e propria, in questo contesto \`e sorto il problema dell'individuazione di una tecnica per la corretta rappresentazione dei tipi. Inizialmente si \`e pensato di adattare la teoria degli isomorfismi ai tipi del linguaggio funzionale che si intendeva utilizzare, successivamente si \`e deciso di tradurre questi tipi in una forma differente che potesse semplificare l'implementazione del modulo adibito al confronto e potesse fornire un disaccoppiamento tra il linguaggio dei tipi utilizzato dai progetti e quello utilizzato per il calcolo delle distanze. Si \`e deciso cio\`e di introdurre il concetto di tipo interno il quale rappresenta una sorta di strumento di lavoro nel calcolo del livello di similarit\`a.

Durante la fase di confronto tra i programmi, \`e stato necessario individuare un modo per confrontare due progetti che erano rappresentati mediante una popolazione di campioni. La teoria della histogram distance~\cite{hist_distance} ha fornito diversi modi per calcolare un valore di distanza, dopo numerosi test sui risultati che si ottenevano applicando le diverse metriche, la Soergel \`e risultata essere quella che offriva i risultati pi\`u realistici, si \`e lasciato comunque a disposizione dell'utilizzatore finale la possibilit\`a di scegliere tra le tre metriche descritte nel capitolo precedente. 

Il problema principale della fase finale dello sviluppo del prototipo \`e stata la ricerca del metodo pi\`u adatto per la presentazione dei risultati ottenuti all'utente. 
Inizialmente si \`e pensato di fornire un risultato booleano che indicasse la presenza o meno di un plagio a seconda che il valore di similarit\`a si trovasse al di sopra o al di sotto di una soglia stabilita, successivamente si \`e giunti alla conclusione che questa soluzione non \`e efficace in quanto il concetto di similarit\`a tra due programmi \`e altamente dipendente dal numero di confronti che si effettuano. Se si possiedono numerosi progetti \`e infatti possibile analizzare la distribuzione delle distanze ed individuare in modo semplice anomalie che possono portare al sospetto di plagio. Inoltre l'analisi della distribuzione risulta essere l'unica soluzione per identificare la distanza tra programmi utilizzando le metriche, come ad esempio la Canberra, che sono dipendenti dal numero di tipi presenti un progetto.

Il tool offrir\`a la possibilit\`a di mostrare a video il livello di similarit\`a tra tutte le coppie di programmi tramite un valore numerico. \`E stato tuttavia ritenuto opportuno individuare un modo per la presentazione grafica dei risultati che prendesse in considerazione le distanze tra tutti i progetti appartenenti ad una determinata specifica (ad esempio tra tutti quelli consegnati nello stesso anno accademico), per questo \`e stato creato uno script il quale permette di gestire in maniera automatica la creazione dei grafici.

Nelle prossime sezioni di questo capitolo verranno mostrati i grafici dei risultati ottenuti, questi verranno analizzati per evidenziare situazioni di plagio o situazioni in cui il tool creato fornisce dei risultati poco accurati. Successivamente verranno confrontati gli approcci esistenti con quello adottato dal nostro tool.
Verranno descritti i lati positivi e quelli negativi del confronto mediante isomorfismi di tipo e verranno indicate le situazioni pratiche in cui il tool fallisce nel riconoscimento del plagio. 
      
\section {Applicabilit\`a degli isomorfismi al contesto} 
Durante la fase di studio di fattibilit\`a del problema \`e stato necessario analizzare l'applicabilit\`a della teoria degli isomorfismi al contesto di confronto di programmi scritti in un linguaggio funzionale. 

\`E stato detto come questa teoria venga attualmente utilizzata come strumento per la ricerca, a partire dai tipi, di funzioni all'interno di un database. 
Applicarla nel confronto di progetti significava incorrere nella possibilit\`a che il concetto di isomorfismo risultasse essere poco o troppo discriminante. 

Da un lato il timore era quello di realizzare un prototipo che considerasse la maggior parte dei programmi simili tra loro. Questo sarebbe potuto accadere a causa del fatto che la definizione di isomorfismo racchiude in s\'e il concetto di semantica di una funzione, si sarebbe potuti arrivare quindi ad una situazione in cui tutti progetti che appartengono ad una determinata specifica venissero considerati isomorfi tra loro.
Questo timore era alimentato anche dal fatto che, essendo $\OCaml$ un linguaggio di programmazione ad alto livello\footnote{Un linguaggio di programmazione di alto livello permette all'utente di astrarre dalla reale implementazione delle strutture dati o delle funzioni.}, il programmatore non possiede numerosi gradi di libert\`a per risolvere un determinato problema (ad esempio nella definizione di una lista non \`e possibile specificare il modo con cui si desidera che questa venga rappresentata in memoria), si sarebbe potuti arrivare alla conclusione che esiste un modo univoco per strutturare un programma e che quindi tutti i progetti fossero equivalenti tra loro.

Dall'altro lato, una volta constatato che il primo timore fosse infondato, rimaneva il dubbio che si potessero considerare come differenti due funzioni con tipi diversi ma che in realt\`a, dall'analisi del codice sorgente, risultassero essere estremamente simili. Il timore era quindi che l'approssimazione derivante da questa analisi forse troppo generica in quanto, valutando solo il tipo, si sarebbe tralasciata un'enorme quantit\`a di informazioni derivabile dal codice e si sarebbe arrivati a considerare tutti i progetti distinti.

I risultati ottenuti permettono, al contrario, di dimostrare come la teoria degli isomorfismi possa fornire dei risultati che sono in linea con quanto ci si aspetta di ottenere.

Nei test che verranno mostrati in questo capitolo sono stati utilizzati 82 progetti suddivisi nel seguente modo:
\begin{itemize}
\item 32 per la realizzazione di un parser LL1 (Tipologia $A$);
\item 30 per la realizzazione di una calcolatrice di espressioni regolari (Tipologia $B$);
\item 20 per la compilazione di un linguaggio imperativo (Tipologia $C$).
\end{itemize}

\begin{figure}
  \begin{center}
    \includegraphics[height=\textwidth, angle=90]{img/A_Soergel_frequency.eps}
	\caption{Frequenza della distribuzione delle distanze su progetti di tipo $A$}
	\label{fig:A_Soergel_frequency}
  \end{center}             
\end{figure}

\begin{figure}
\centering
	\includegraphics[height=\textwidth, angle=90]{img/B_Soergel_frequency.eps}
	\caption{Frequenza della distribuzione delle distanze su progetti di tipo $B$}
	\label{fig:B_Soergel_frequency}
\end{figure}

Nella figura~\ref{fig:A_Soergel_frequency} \`e raffigurato il grafico che mostra la frequenza di distribuzione delle distanze in un intervallo tra $0\%$ (simili) e $100\%$ (diversi) su un insieme di progetti dello stesso tipo $A$.
La cifra indicata nella parte superiore delle barre rappresenta il numero di valori che si trovano in quell'intervallo. 
Ad esempio, per l'assegnamento di tipo $A$ sono presenti 32 interfacce che, come esposto nella sezione~\ref{utilizzi.tool}, porteranno ad un totale di 496 confronti:
\[
n_{test} = {{n \times (n-1)}\over{2}} = {{32 \times (31)}\over{2}} = 496
\]
di queste 491 sono comprese nell'intervallo 90\%--100\%, quattro nel 80\%--90\% e solo una avr\`a un valore di distanza compreso tra il 30\%--40\%. 

Dalla figura~\ref{fig:B_Soergel_frequency}, la quale rappresenta la stessa frequenza ma su un insieme di interfacce appartenenti alla specifica $B$, \`e chiaro come siano presenti anche numerose situazioni in cui il tool restituisce valori di distanza pi\`u bassi, si possono infatti notare ben otto valori al di sotto del 30\%.\footnote{Per quanto riguarda i progetti di tipo $C$, la distribuzione delle frequenze \`e estremamente simile a quella esposta per l'assegnamento $B$.} 

La distribuzione dei valori delle distanze nei due grafici rispecchia quello che ci si aspettava di ottenere. Nonostante alcuni progetti vengano considerati come plagiati, la maggior parte di questi sono posizionati nell'intervallo 90\%--100\% ovvero possono essere dichiarati originali. 
La prima figura in particolare enfatizza il fatto che l'espressivit\`a della teoria degli isomorfismi permette di mantenere una netta separazione tra le interfacce che appartengono alla medesima specifica.
La seconda evidenzia come, nonostante non venga considerato il codice sorgente di un programma, l'astrazione che si ottiene considerando solo i tipi delle funzioni \`e tale per cui \`e possibile individuare anche situazioni in cui vi \`e una forte similarit\`a (e quindi un sospetto di plagio).


Considerando pi\`u nello specifico il concetto di semantica, ci si aspetterebbe inoltre che la rappresentazione su un piano spaziale delle distanze di tutti i progetti portasse alla situazione in cui sono evidenti degli agglomerati che rappresentano le diverse tipologie di assegnamento. 
Questo \`e mostrato in modo chiaro nella figura~\ref{ALL_Soergel_global_scatter_group} la quale rappresenta la distribuzione spaziale delle distanze calcolate su tutti i programmi che si avevano a disposizione. 
Per ottenere questa rappresentazione si \`e effettuato uno scaling multidimensionale della matrice delle distanze ottenuta utilizzando il prototipo creato. 
Tramite questa tecnica, che viene utilizzata frequentemente in analisi statistica, \`e stato possibile ottenere un ulteriore matrice composta da tante linee quante sono i progetti e, per ciascuno di essi, un insieme di $n$ valori che ne rappresentano le coordinate in uno spazio n-dimensionale.
Prendendo in considerazione solo i primi due elementi di ciascuna riga \`e stato possibile ottenere le coordinate approssimate $(x,y)$ di un progetto nel piano.
In questo modo si \`e riusciti a far si che la distanza geometrica tra due punti del piano sia ---~approssimativamente~--- pari alla distanza calcolata dal nostro tool.

\begin{figure}
  \begin{center}
    \includegraphics[height=\textwidth, angle=90]{img/ALL_Soergel_global_scatter_tr_color.eps}
	\caption{Distribuzione spaziale delle distanze Soergel su tutti i progetti}
	\label{ALL_Soergel_global_scatter_group}
  \end{center}             
\end{figure}
In questa figura \`e possibile notare chiaramente come i progetti dello stesso tipo tendono ad agglomerarsi e a formare cluster uniformi.

Una situazione particolare \`e evidente per i progetti appartenenti alla specifica $B$, \`e possibile notare infatti come sette di questi vengano posizionati in modo distaccato rispetto agli altri. Questo non rappresenta un errore nel calcolo delle distanze bens\`i indica la presenza di sette progetti che presumibilmente hanno adottato una soluzione differente nella risoluzione del problema. Questa situazione potrebbe essere indice di una collaborazione tra i sette studenti oppure potrebbe rappresentare semplicemente un errore che accade di frequente nella risoluzione di questo tipo di assegnamento. Pi\`u avanti in questo capitolo nella sezione~\ref{sez:valutazione} si cercher\`a di individuare la causa per la quale le interfacce si dispongono in questo modo.

In conclusione possiamo affermare che la tecnica di confronto basata su isomorfismi di tipo permette potenzialmente di comparare in modo corretto la semantica di programmi funzionali. Nelle prossime sezioni di questo capitolo verranno mostrate le differenze tra il calcolo della distanza effettuato mediante metriche differenti e verr\`a valutata l'affidabilit\`a del software anche comparandolo con i tool attualmente esistenti.

\section{Confronto tra le metriche di distanza}
\label{sez:confronto}
\`E stato detto nel capitolo precedente come sia possibile calcolare il grado di similitudine tra programmi (la distanza) in modi differenti. \`E possibile utilizzare cio\`e diverse metriche che, basandosi sulle stesse tabelle che rappresentano il numero di funzioni per ciascun tipo, permettono di ottenere risultati diversi. Per ciascuna di esse \`e stata descritta l'intuizione che vi \`e alla base, in questo paragrafo verranno mostrati i risultati ottenuti.

\begin{figure}
  \begin{center}
	\includegraphics[height=\textwidth, angle=90] {img/ALL_Sharing_global_scatter_group_color.eps}
  \end{center}             
  \caption {Distribuzione spaziale delle distanze Sharing su tutti i progetti}
\label{fig:ALL_Sharing_global_scatter_group} 
\end{figure}

\begin{figure}
  \begin{center}
	\includegraphics[height=\textwidth, angle=90] {img/ALL_Canberra_global_scatter_group_color.eps}
  \end{center}             
  \caption{Distribuzione spaziale delle distanze Canberra su tutti i progetti}
  \label{fig:ALL_Canberra_global_scatter_group}
\end{figure}

Le figure~\ref{fig:ALL_Sharing_global_scatter_group} e~\ref{fig:ALL_Canberra_global_scatter_group}, mostrano i grafici della distribuzione spaziale di tutti i progetti ottenuti utilizzando rispettivamente le metriche Sharing e Canberra. 

La differenza principale tra questi due tipi di calcolo \`e che la seconda distanza non \`e normalizzata tra $0$ e $1$. Come \`e stato detto questa sar\`a dipendente dal numero di tipi presenti all'interno di un progetto, \`e chiara quindi la motivazione per la quale l'interfaccia numero $49$ \`e posizionata in modo cos\`i distaccato rispetto alle altre. \`E infatti possibile notare che nella quasi totalit\`a dei moduli componenti questo programma sono presenti delle definizioni di funzioni che sono generate automaticamente nel momento in cui vengono utilizzati i funtori Set per la rappresentazione di insiemi.

Nonostante questa diversa disposizione spaziale dei risultati \`e possibile ritrovare in entrambi grafici le situazioni in cui due progetti vengono considerati a distanza pressoch\'e zero. Ad esempio le coppie $(4, 43)$ e $(53, 66)$ sono chiaramente sovrapposte sia nel grafico Canberra che in quello Sharing. Questo dimostra come, nonostante i risultati siano differenti, le situazioni in cui sorge il sospetto di plagio vengono riconosciute da entrambe le distanze.

\begin{figure}
  \begin{center}
    \includegraphics[height=\textwidth, angle=90]{img/A_combo_min_cross_distance.eps}
	\caption{Distanza minima (rif.Soergel) calcolata tramite Soergel e Sharing dei progetti A}
	\label{fig:A_combo_min_cross_distance}
  \end{center}             
\end{figure}

Il grafico mostrato nella figura~\ref{fig:A_combo_min_cross_distance} individua, per ogni programma appartenente alla tipologia $A$, quello che si trova a distanza minima in base alla metrica Soergel, successivamente mostra il valore di distanza su questa coppia ottenuto utilizzando la Sharing. 
Questa rappresentazione permette di effettuare un raffronto tra i valori ottenuti tramite queste due metriche.

Come ci si aspettava la distanza Sharing, analizzando il grado di condivisione, restituisce valori di distanza leggermente pi\`u bassi rispetto alla Soergel, ma tuttavia in linea con questi. 

Un caso particolare si ottiene per i $(23, 54)$, analizzando queste interfacce  \`e possibile notare come la maggior parte dei tipi sia presente in entrambi i progetti. La differenza fondamentale sta nel fatto che il $23$ utilizza in pi\`u la definizione di un funtore Set il quale genera $24$ valori che non sono presenti all'interno del $54$. Come descritto nel capitolo precedente, la distanza Sharing andando a valutare il grado di condivisione considerer\`a solo i valori condivisi e quindi questi due progetti risulteranno essere molto vicini.

Se da un lato \`e quindi presente la distanza Canberra la quale considera, nella valutazione della distanza, il numero di tipi presenti in ciascuno di essi, dall'altro la metrica Sharing fornisce un valore normalizzato che dipende dalla reale condivisione di funzioni tra i due progetti.

In una prima analisi si potrebbe pensare che il numero dei tipi fornisca un livello della differenza tra due interfacce; non \`e propriamente sbagliato sostenere che due interfacce contenenti un numero molto differente di tipi debbano essere considerate come molto distinte. Sotto queste ipotesi si potrebbe affermare che la metrica Canberra sia la migliore, tuttavia \`e possibile che siano presenti all'interno di un progetto numerose funzioni che non vengono utilizzate in pratica oppure che servono esclusivamente per scopi di debugging. Nel primo caso durante la compilazione dell'eseguibile verrebbero mostrati dei messaggi di warning che potrebbero far insospettire l'esaminatore, nel caso di funzioni adibite a scopi di debug (ad esempio per la stampa a video di valori intermedi) queste non possono essere considerate significative nella valutazione della differenza tra due programmi, quindi una metrica che valuta la reale condivisione tra due progetti fornirebbe risultati pi\`u accurati.

A tal proposito durante l'ispezione delle interfacce che si avevano a disposizione si \`e notato che la quasi totalit\`a di queste contenevano numerose funzioni le quali erano state generate automaticamente durante la creazione dei lexer o parser. Queste funzioni non essendo state genuinamente create dagli studenti non potevano essere considerate nella valutazione della similarit\`a tra due programmi, pertanto si \`e deciso di non considerarle e di eliminarle dall'interfaccia. Lo stesso \`e stato effettuato con alcuni moduli forniti dal docente che non risultavano essere significativi nel calcolo della distanza.

A questo punto \`e chiaro quindi il motivo per cui \`e stata considerata come metrica di riferimento (quella scelta per default dal tool) la Soergel, in quanto fornisce un valore intermedio tra i due estremi esposti in precedenza tentando, a differenza di Canberra di normalizzare la distanza sul numero dei tipi e considerando rispetto a Sharing anche il numero di funzioni che sono presenti in un solo progetto.

Non \`e tuttavia possibile definire la metrica migliore, in quanto ciascuna di esse fornisce un modo differente per calcolare la distanza tra due progetti. \`E questo il motivo principale per cui si \`e scelto di offrire la possibilit\`a all'utilizzatore di selezionare il modo con cui desidera che venga interpretato il concetto di distanza.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Valutazione dei risultati ottenuti}
\label{sez:valutazione}
Nel valutare l'affidabilit\`a dei risultati ottenuti mediante il prototipo realizzato non \`e possibile seguire un approccio strettamente empirico. Non \`e possibile cio\`e definire una percentuale che rappresenta la quantit\`a di progetti realmente copiati che vengono riconosciuti dal tool creato. Generalmente infatti gli studenti insieme al progetto non consegnano una dichiarazione esplicita di copiatura, inoltre sarebbe opportuno individuare anche situazioni in cui vi \`e stata collaborazione. 
Per questo motivo nella valutazione della qualit\`a dei risultati si andranno ad analizzare in dettaglio i progetti che, secondo il tool, devono destare sospetto. 
I risultati ottenuti verranno poi confrontati quelli che si ottengono utilizzando gli strumenti attualmente esistenti per il rilevamento del plagio che utilizzano un approccio basato sulla struttura.
In particolare verranno mostrate le differenze con i tool Moss e Jplag.\footnote{Nel primo caso \`e stato possibile specificare che il linguaggio di programmazione utilizzato appartiene alla famiglia ML, nel secondo caso i sorgenti verranno considerati come semplici file di testo. Per una descrizione del funzionamento di questi tool si rimanda al capitolo~\ref{cap:introduzione}.}

La figura~\ref{fig:A_combo_min_cross} mostra, per ogni progetto di tipo $A$, quello che si trova a distanza minima secondo la metrica Soergel e per ciascuna coppia visualizza il valore calcolato tramite l'uso di Moss e Jplag.
\begin{figure}
  \begin{center}
    \includegraphics[height=\textwidth, angle=90]{img/A_combo_min_cross_BW.eps}
	\caption{Confronto risultati con tool esistenti su un campione di progetti di tipo $A$}
	\label{fig:A_combo_min_cross}
  \end{center}             
\end{figure}

Esaminando i risultati si nota come la maggior parte di questi siano conformi a quello che si aspettava di ottenere, lo scostamento maggiore lo si pu\`o notare tra i programmi $(2,58)$ dove, il nostro tool, restituisce un valore di distanza molto pi\`u alto di quelli ottenuti utilizzando Jplag e Moss.

Analizzando le interfacce si nota la presenza di alcune differenze sui tipi utilizzati. In entrambi \`e infatti presente la dichiarazione di un tipo algebrico che viene utilizzato per la definizione di un albero di sintassi astratta, la differenza \`e che il numero $2$ utilizza $\tstring$ al posto di $\tchar$ come tipo di un costruttore \texttt{Term}. 
Questo viene rappresentato nel seguente modo:
\begin{center}
\centering
\textbf {Progetto 2}
\centering
\begin{verbatim}
type symbol = 
  Var of string 
    | Term of string 
    | Epsilon of string
type gram = 
  Gram of string * prod list
and prod = 
  Prod of string * symbol list
\end{verbatim}
\textbf {Progetto 58}
\begin{verbatim}
type symbol = 
  NTerm of string 
    | Term of char 
    | Epsilon of string
type grammar = 
  Gram of string * prod list
and prod = 
  Prod of string * symbol list
\end{verbatim}
\end{center}
Si potrebbe pensare che la modifica del tipo di un costruttore implichi l'aggiornamento di tutti i segmenti di codice che lo utilizzano, tuttavia il linguaggio $\OCaml$ presenta una caratteristica particolare denominata overloading che permette di utilizzare una funzione o un operatore su qualunque tipo di dato.\footnote{Ad esempio, \`e possibile verificare l'uguaglianza di due elementi qualunque semplicemente tramite l'operatore \texttt{=}. In modo del tutto trasparente all'utente il compilatore verificher\`a a quali tipi questo \`e applicato e invocher\`a la funzione idonea per effettuarne il confronto.} 
Questa caratteristica consente, ad esempio, di rendere estremamente semplice la modifica del tipo di un costruttore che viene utilizzato principalmente in espressioni di confronto.

Data la struttura del nostro tool questa differenza si propagher\`a in tutte le funzioni che utilizzano questo tipo algebrico (nel caso specifico 21 su un totale di 30) in quanto nel calcolo della distanza il prototipo andr\`a a valutare le differenze tra le funzioni nelle quali ogni occorrenza di un tipo definito dall'utente viene sostituita con la sua definizione.

L'influenza di questa modifica nel calcolo della similitudine tra questi due programmi pu\`o essere dimostrata modificando manualmente il tipo del costruttore \texttt{Term} nel progetto numero 58. Se si sostituisce $\tchar$ con $\tstring$ il valore di distanza risulter\`a essere pari a $0,4$, valore che permette di identificare una possibile situazione sospetta.

Un'altra differenza tra questi due progetti \`e che all'interno del $2$ non \`e presente la dichiarazione di un modulo adibito al calcolo del follow. Non essendo necessario per il raggiungimento di una valutazione sufficiente, probabilmente lo studente ha deciso di eliminare questo modulo per nascondere la copiatura.
Come sappiamo la distanza Sharing permette di individuare proprio queste situazioni, \`e possibile cio\`e identificare la situazione in cui un progetto \`e incluso all'interno di un altro. Se si calcola la distanza specificando questa metrica (dopo aver sostituito $\tchar$ con $\tstring$) otteniamo infatti il valore $0,1$ che indica una situazione sicuramente sospetta.
 
Il confronto tra i codici sorgente di questi due progetti permette di individuare il motivo per cui Moss e Jplag forniscono valori di distanza cos\`i bassi. \`E importante precisare che il tool Jplag non \`e a conoscenza del lessico utilizzato per scrivere questi programmi, presumibilmente quindi sono state valutate anche le porzioni di codice commentato.
Moss, al contrario, nonostante non consideri i commenti, \`e capace di individuare le numerose similitudini nella struttura delle funzioni, inoltre nel calcolo della distanza, la differenza nella definizione del tipo algebrico rimarr\`a confinata al punto in cui questa viene dichiarata e non si propagher\`a quindi in tutti gli utilizzi come nel caso del nostro tool.

In conclusione \`e possibile dedurre, che in questi due progetti vi sia stata la collaborazione di due studenti che, lavorando in parallelo, hanno adottato soluzioni piuttosto differenti per risolvere lo stesso problema. Tuttavia queste soluzioni non risultano essere isomorfe, pertanto il nostro tool non \`e in grado di identificare questi due progetti come simili. 
In particolare la possibilit\`a di ingannare il prototipo creato modificando il solo tipo di un costruttore rappresenta una debolezza del nostro approccio amplificata anche dal fatto che, per via dell'overloading degli operatori, nella maggior parte dei casi \`e possibile modificare un tipo in maniera piuttosto semplice senza dover ristrutturare completamente le funzioni che operano su questo dato.

Per i progetti $(23,54)$, la situazione \`e opposta alla precedente, ovvero il prototipo da noi realizzato restituisce un valore di similitudine pi\`u basso rispetto agli altri.

In questo caso l'analisi dei file di interfaccia permette di identificare una situazione che \`e chiaramente sospetta. Come ampiamente documentato in letteratura~\cite{Towards_2008, Identification_1990, Plagiarism_1996, Software_1996} questo \`e un tipico esempio di plagio nel quale le differenze principali riguardano la disposizione delle funzioni all'interno dei moduli o la ridenominazione dei valori.
\`E chiaro come l'analisi dei tipi risulti essere molto pi\`u efficace nell'identificazione del plagio rispetto ad un approccio basato sulla sintassi il quale analizza porzioni di codice ed identifica il livello di similitudine in base alla lunghezza di questi segmenti. 
La valutazione della similitudine sintattica tra questi due programmi nei quali sono state effettuate numerose ridenominazioni risulta essere quindi estremamente complicata.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}
  \begin{center}
    \includegraphics[height=\textwidth, angle=90]{img/B_combo_min_cross_BW.eps}
    \caption{Confronto risultati con tool esistenti su un campione di progetti di tipo $B$}
	\label{fig:B_combo_min_cross}

  \end{center}             
\end{figure}

Come esposto nella prima sezione di questo capitolo quando sono state mostrate le frequenze di distribuzione delle distanze, tra i progetti che appartengono all'assegnamento $B$ sono presenti un numero maggiore di programmi che presentano livelli di similitudine che potrebbero destare un sospetto di plagio.

Il grafico comparativo che riguarda questi progetti \`e esposto nella figura~\ref{fig:B_combo_min_cross}.
Come si pu\`o notare in questo assegnamento il fenomeno del plagio \`e stato pi\`u rilevante, i progetti $(28,80)$, $(4,43)$ e $(53,66)$ si trovano infatti a distanza zero secondo il nostro tool. 

Da un'ispezione di queste interfacce \`e palese il fatto che ci sia stato uno scambio dei sorgenti tra gli studenti e che lo sforzo maggiore sia stato effettuato principalmente nella traduzione dei nomi delle funzioni. I risultati ottenuti utilizzando Moss, seppur non a $0$, mostrano comunque una situazione sospetta. Jplag, come detto precedentemente, considerando i file come semplice testo, analizza anche le differenze lessicali tra i programmi e pertanto non mostra nessuna anomalia.

Anche in questo caso, come per assegnamento $A$, \`e presente una coppia di progetti $(42, 63)$ che in base al calcolo effettuato mediante nostro tool presenta un valore di distanza pi\`u alto di quello ottenuto utilizzando Moss. Dalle interfacce si pu\`o notare che la differenza principale sta nella definizione di un tipo algebrico e come questa modifica si ripercuote in numerose funzioni all'interno di tutti i moduli. Moss, nuovamente, analizzando le similitudini sintattiche, \`e in grado di individuare i numerosi elementi in comune tra questi progetti.

I restanti valori di distanza possono essere considerati in linea con quelli ottenuti mediante gli altri tool. 

Come esposto nella sezione~\ref{sez:confronto} la disposizione spaziale dei progetti ottenuta utilizzando la metrica Soergel presenta una caratteristica interessante.
Come \`e possibile notare dalla figura~\ref{ALL_Soergel_global_scatter_group}, infatti, sette progetti che appartengono all'assegnamento $B$ sono posizionati in modo distaccato rispetto agli altri. 
Inoltre \`e possibile notare che sono presenti alcuni progetti di tipo $A$ tra questi due sotto-cluster. 
Analizzando le sette interfacce disposte nella parte inferiore del grafico \`e possibile notare chiaramente come siano presenti numerosi elementi in comune che giustificano il fatto che queste si trovino vicine tra loro. Lo stesso accade per i restanti progetti che vengono collocati nella parte superiore sinistra. 
La differenza tra questi due gruppi risiede principalmente nella definizione del tipo algebrico utilizzato per rappresentare le espressioni regolari che vengono fornite dall'utente. Queste vengono definite nel seguente modo:

\begin{center}
\centering
\textbf {Progetti corretti}
\centering
\begin{verbatim}
type expr = 
  Epsilon 
    | Carattere of char 
    | A 
    | Stella of expr 
    | Unione of expr * expr 
    | Concatenazione of expr * expr 
type stmt = 
  RelUguaglianza of expr * expr 
    | RelInclusione of expr * expr 
\end{verbatim}

\textbf {Progetti distaccati}
\begin{verbatim}
type expr = 
  Epsilon 
    | Carattere of char
    | Stella of expr 
    | Unione of expr * expr 
    | Concatenazione of expr * expr
    | RelUguaglianza of expr * expr 
    | RelInclusione of expr * expr 
\end{verbatim}
\end{center}

Come si pu\`o notare nei sette progetti che si trovano in posizione distaccata, all'interno del tipo algebrico che permette di definire la struttura di una espressione, sono stati inseriti i due costruttori che rappresentano le relazioni di uguaglianza o di inclusione tra queste.

Tuttavia questa definizione non \`e semanticamente corretta. Non \`e possibile sostenere che le relazioni di uguaglianza o di inclusione siano delle espressioni, queste al contrario possono essere viste esclusivamente come due operatori che operano sul tipo \texttt{expr}. Sotto queste condizioni si pu\`o affermare che il modo corretto per rappresentare questo tipo di dato sia quello che la maggior parte degli studenti hanno utilizzato nella risoluzione del progetto.

Come gi\`a accennato nella sezione precedente questa separazione tra le interfacce quindi non rappresenta un errore nel calcolo delle distanze bens\`i \`e indice di una corretta valutazione della semantica dei progetti. \`E una caratteristica fondamentale la capacit\`a del nostro approccio di riuscire ad evidenziare le situazioni in cui gruppi di progetti utilizzano soluzioni differenti nella risoluzione dello stesso assegnamento.

\subsection{Prestazioni}
Per quanto riguarda le prestazioni del tool, i tempi necessari per effettuare il calcolo della distanza sui progetti che si avevano a disposizione sono:\footnote{I tempi riportati si intendono espressi in secondi.}
\begin{itemize}
\item calcolo della distanza tra due progetti (ottenuti effettuando i 3321 confronti incrociati delle tipologie $A$, $B$ e $C$):
	\subitem tempo minimo: 0.002 per i progetti $(15,24)$, $(24,36)$ e $(24.39)$ 
	\subitem tempo massimo: 1.596 per i progetti $(76,65)$
	\subitem tempo medio: 0.104;
\item focus su tutti i progetti:
	\subitem tipo $A$ (31 confronti): 1.475;
	\subitem tipo $B$ (29 confronti): 2.835;
\item controlli incrociati su progetti:
	\subitem tipo $A$ (496 confronti): 18.046;
	\subitem tipo $B$ (435 confronti): 20.249;
	\subitem tipo $C$ (190 confronti): 130 
	\subitem tipo $A$ e $B$ (1891 confronti): 80.919;
	\subitem tipo $A$, $B$ e $C$ (3321 confronti): 353.912;
\end{itemize}
I tempi sono stati calcolati utilizzando un Apple$^\copyright$ MacBook con processore Intel$^\copyright$ Core 2 Duo 2Ghz, 2 GB di SDRAM DDR2 da 667 MHz con sistema operativo Mac OS X Leopard (10.5.8-Kernel Darwin9.8.0). 
L'eseguibile \texttt{isotype.opt} \`e stato compilato in codice nativo ottimizzato, mediante il compilatore \texttt{ocamlopt} \`e stato possibile cio\`e produrre un eseguibile pi\`u efficiente rispetto a quello ottenuto mediante una compilazione tradizionale, questo ha permesso di ridurre tempi di calcolo dell'80\% circa (6/7 minuti piuttosto che 30).

Da questi valori \`e possibile notare come il confronto tra i progetti appartenenti alla tipologia $C$ richieda un tempo sei volte superiore a quello necessario per le altre due categorie di assegnamenti. 
Questo \`e sicuramente dovuto al fatto che all'interno di queste interfacce sono presenti numerosi tipi algebrici (molto complessi) che richiedono molto tempo per essere risolti e confrontati.  

I risultati ottenuti permettono tuttavia di concludere che l'approccio utilizzato, nonostante consideri la semantica dei programmi e quindi operi ad un livello di astrazione elevato, permette di mantenere i tempi di calcolo su livelli ragionevoli. 
Naturalmente questi tempi sono superiori a quelli necessari per effettuare una valutazione di tipo sintattico sul codice sorgente, questo per\`o era stato previsto gi\`a durante la fase di analisi del problema in quanto solitamente all'aumentare del livello di astrazione si assiste ad un aumento del tempo di esecuzione. 

\subsection{In conclusione}
In conclusione possiamo affermare che il nostro approccio basato sull'utilizzo degli isomorfismi di tipo permette di calcolare in modo corretto la similitudine semantica tra progetti funzionali.

Come diretta conseguenza del fatto che non vengono esaminati direttamente i codici sorgente ma che vengono analizzate le interfacce \`e possibile astrarre totalmente dalla struttura che un programmatore decide di assegnare ad una funzione. 

Ad esempio le due funzioni:
\begin{verbatim}
function 
   x, y -> 
      if x > y then x 
	  else 0 

function 
   x, y when x > y -> x 
 | _ -> 0 
\end{verbatim}
produrranno la stessa interfaccia indipendentemente dal fatto che venga utilizzato il costrutto (la funzione) \textit{if} piuttosto che un \textit{pattern matching}.

Dal lato opposto la soluzione che viene adottata dal nostro prototipo presenta il problema di essere altamente sensibile alle definizioni dei tipi algebrici che vengono utilizzati frequentemente all'interno di un progetto. 
Come \`e possibile notare dalla valutazione dei risultati ottenuti, infatti, nel momento in cui viene definito un tipo algebrico, ogni riferimento al suo utilizzo verr\`a sostituito con la sua definizione. 
Nel caso in cui due progetti abbiano la stessa struttura, ma che in uno di questi venga modificato il tipo di un costruttore, il risultato che ne deriva \`e che questa modifica verr\`a propagata in tutte le funzioni che utilizzano il tipo algebrico. 
Se i tipi di partenza non risultano essere isomorfi, secondo la definizione data in questa tesi, il calcolo della distanza ne viene influenzato pesantemente.
Ad esempio i due moduli:
\[
\begin{array}{ll}
\textbf{Progetto 1} & \textbf{Progetto 2}   \\
\verb! module A :				!&\verb! module A :					!  	\\
\verb! sig						!&\verb! sig						!  	\\
\verb! type 'a lista =			!&\verb! type 'a lista =			!  	\\
\verb!   Empty					!&\verb!   Empty					!  	\\
\verb!   | Null					!&\verb!   							!  	\\
\verb!   | Cons of 'a * 'a list	!&\verb!   | Cons of 'a * 'a list	!  	\\
\verb! val remove_duplicates : 	!&\verb! val remove_duplicates : 	!  	\\
\verb!   int lista -> int lista !&\verb!   int lista -> int lista 	! \\
\verb! val remove_duplicates2 : !&\verb! val remove_duplicates2 : 	!  	\\
\verb!   int lista -> int lista !&\verb!   int lista -> int lista 	! \\
\verb! val create :		 		!&\verb! val create :			 	!  	\\
\verb!   int -> int lista 		!&\verb!   int  -> int lista 		! \\
\verb! end  					!&\verb!  end  						!  \\
\end{array}
\]
la cui differenza \`e esclusivamente nella definizione del costruttore del tipo \texttt{lista}, si troveranno a distanza $1$ indipendentemente dal fatto che siano presenti numerose funzioni, anche identiche tra i due progetti, che utilizzano il tipo \texttt{lista}. 

\`E necessario precisare inoltre che a livello di interfaccia non vi \`e nessuna informazione sul fatto che \texttt{Null} non venga mai utilizzato, tuttavia l'introduzione di un costruttore comporta il fatto che debbano essere modificati tutti i pattern matching che operano sul tipo algebrico. Se non viene effettuata questa operazione verranno mostrati dei messaggi di warning che potrebbero far sorgere sospetti gi\`a durante la fase di compilazione dell'eseguibile. La modifica alla struttura di un tipo algebrico \`e quindi un'operazione che implica numerose modifiche e una buona conoscenza del codice sorgente sul quale si sta operando.

Questo tuttavia \`e valido solo nel momento in cui si modifichi la \emph{struttura} del tipo somma, come abbiamo visto nella sezione~\ref{sez:confronto} per i progetti $(2,58)$, nel caso in cui venga cambiato un tipo atomico all'interno di un costruttore la caratteristica di overloading degli operatori permetterebbe di ridurre al minimo gli interventi che ne derivano.

Come possibile sviluppo futuro del nostro tool \`e possibile quindi prevedere da un lato l'individuazione di una tecnica che permetta di risolvere il problema delle modifiche alla struttura dei tipi algebrici che vengono frequentemente utilizzati all'interno delle interfacce, dall'altro per evitare che la modifica del tipo di un costruttore possa comportare un'analisi errata, si potrebbe valutare la possibilit\`a di considerare isomorfi tutti i tipi atomici. 
La conseguenza di questa modifica comporterebbe per\`o che i valori delle distanze diminuirebbero in maniera sostanziale, nella rappresentazione spaziale dei progetti cio\`e questi tenderebbero ad avvicinarsi molto tra loro.
Questa soluzione non \`e stata implementata all'interno del nostro prototipo in quanto si desiderava applicare, nel modo pi\`u fedele possibile, la teoria degli isomorfismi gi\`a presente in letteratura all'ambito del calcolo del livello di similarit\`a.

Come pi\`u volte detto in questa tesi il confronto tra progetti avviene a livello semantico, sotto queste considerazioni \`e possibile affermare che esista una semantica che appartiene alla specifica. Ovvero esister\`a almeno una struttura di progetto che pu\`o essere considerata corretta. Sarebbe interessante valutare se si ottengono risultati pi\`u accurati se si indica al tool qual'\`e la semantica corretta di un programma che assolve ad una determinata specifica. Sarebbe possibile cio\`e prendere come riferimento un progetto, magari creato ad-hoc dall'esaminatore, e valutare quali sono le modifiche che un programmatore apporta relativamente a questo. In questo modo si riuscirebbe ad evitare di considerare come isomorfi due programmi genuini che hanno adottato la tecnica corretta (a livello di struttura del programma) nella risoluzione del problema. 
Nell'eventualit\`a che questa soluzione portasse a risultati interessanti si potrebbe prevedere l'introduzione di un flag che permetta di specificare se si desidera effettuare un confronto incrociato tra tutti progetti oppure relativo soltanto ad uno preso come riferimento.

Come ultimo raffinamento sarebbe opportuno considerare la creazione di una interfaccia utente che permetta di semplificare l'utilizzo del tool, magari demandando a questa la creazione dei grafici i quali sono risultati essere estremamente utili nella valutazione di situazioni sospette.

Infine possiamo affermare che nella creazione di un prototipo per la misura della similarit\`a tra programmi non \`e possibile individuare un approccio migliore in assoluto. 
Come abbiamo visto in questa tesi gli approcci attualmente esistenti in alcuni casi si dimostrano essere pi\`u efficaci mentre per altri tipi di modifiche un'analisi dei tipi risulta essere fondamentale per riuscire ad astrarre dal reale contenuto del codice sorgente. Uno strumento efficace potrebbe essere composto dalla combinazione di tutte queste tecniche, magari integrate con la valutazione dei messaggi di compilazione che permetterebbe di aumentare l'insieme degli indizi che alla fine andranno a costituire la prova.



%%% Local Variables: 
%%% mode: latex 
%%% TeX-master: "tesi" 
%%% End: 
